The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.
Multiple asynchronous clocks are used in a wide variety of hardware designs. For example, asynchronous clocks may be used in a system-on-a-chip (SOC). An SOC is a chip including hardware and electronic circuitry for a system. For example, an SOC may include on-chip memory (RAM and/or ROM), a microprocessor, peripheral interfaces, I/O logic control, data converters, and/or other components.
Asynchronous clocks may be used advantageously in SOCs to support multiple bus systems. For example, asynchronous clocks may be used to support an advanced RISC (reduced instruction set computer) machine (ARM) processor, a Peripheral Serial Bus (PCI), and a Universal Serial Bus (USB). Furthermore, asynchronous clocks may be used in large size SOCs that cannot use a single “fast” clock (i.e. synchronous clock) due to transmission delays.
In systems that include more than one clock signal, logic components that are clocked by each clock signal are referred to as clock domains. Logic within a clock domain may be verified using the same technique as for a single clock signal. In other words, a clock domain includes all logic that operates synchronously on one clock signal, even though the logic may have multiple clock signal sources.
A synchronous clock domain is aligned at a clock edge. Setup and hold times of logic components within the clock domain may be verified by comparing the clock delay to delays of signals propagating from one flip-flop to another flip-flop. For example, if the clock delay is the same for two flip-flops (i.e. A and B), configured such that the output of A is the input of B, then the delay of A's output to B's input (i.e. the A-B delay) must be greater than or equal to B's input hold time requirements and less than or equal to B's input setup time requirement.
However, if the clock delay to A and to B is not the same, there is “clock skew” present. Clock skew may be considered when verifying setup and hold times. For example, if the clock skew in the above example is 100 ps (i.e. the clock delay to B is 100 ps longer than to A), then the A-B delay may need to be 100 ps longer in order to avoid violating B's input setup time requirement. Similarly, A's output delay could be 100 ps longer and still make the input setup time of flop B compared to if there were no clock skew.
If logic is not verified, errors such as incorrect outputs may occur. The errors may propagate and cause a chip failure. For example, an asynchronous clock may cause a flip-flop or other device in the second clock domain to experience metastability. Metastability is an undesirable state where the device may hold an incorrect value. In other words, metastability may cause the value of a flip-flop to take many times longer than normal to settle into a correct state, or to oscillate several times between states before settling into one state (i.e. stabilize). Furthermore, metastability may propagate from one device to another device causing a chain of devices to experience metastability.
In asynchronous clock domain crossings (CDCs), the above verification technique may not be used. CDC occurs when an output of one flip-flop has a logical (i.e. combinatorial) path to an input of another flip-flop in a different clock domain. However, a circuit may be employed to communicate between the logic in different clock domains. The technique is called synchronization, and the logic that implements synchronization is called a synchronizer. Synchronizers prevent input setup and hold times of flip-flops and other devices from being violated outside the synchronizer logic. However, synchronizers are usually unable to tolerate setup and/or hold violations.
Referring now to FIG. 1A, an exemplary hardware design 100 where metastability may occur due clock domain crossing (CDC) is shown. CLK_A Domain 110 is driven by CLK_A and CLK_B Domain 120 is driven by CLK_B. For example, CLK_A and CLK_B may be driven by different oscillators. Devices in each clock domain are driven by their respective clocks. For example, D-flip-flops DFF_A 130 and DFF_B 140 are driven by CLK_A and CLK_B, respectively. DFF_A 130 stores signal D when triggered at a rising edge of CLK_A. The output of DFF_A 130, signal DA, is stored in DFF_B 140 at a rising edge of CLK_B. DFF_B 140 produces an output signal DB.
Referring now to FIG. 1B, an exemplary timing diagram that corresponds to the exemplary hardware design 100 of FIG. 1A is shown. The timing diagram illustrates metastability resulting from clock domain crossing (CDC). The rising edge of CLK_B occurs during a transition of signal DA. In such a case, DFF_B 140 samples signal DA in an intermediate state (i.e. when DA is between high and low states). Consequently, setup time and hold time requirements of DFF_B 140 may be violated. The violation may cause DFF_B 140 to become metastable, as shown by a metastable region 150 of signal DB, where the value of signal DB may be uncertain. As previously mentioned, uncertainty (i.e. metastability) is highly undesirable in a hardware design.
To avoid metastability while still allowing signals to be passed between different clock domains, synchronizers may be used to connect the clock domains. Synchronizers may be either single-bit synchronizers or multiple-bit (i.e. bus) synchronizers. For example, single-bit synchronizers may include two D-flip-flop (2DFF) synchronizers and pulse synchronizers. For example, multiple-bit synchronizers may include multiple 2DFF synchronizers, multiplexer (MUX) control synchronizers, handshake synchronizers, and first-in-first-out (FIFO) synchronizers. Of these, the most commonly used synchronizer design is the 2DFF synchronizer.
Referring now to FIG. 2, a 2DFF synchronizer 200 is shown. A flip-flop DFF_A 230 is located in a CLK_A Domain 210. DFF_A 230 is not considered one of the two flip-flops of the 2DFF synchronizer 200. The 2DFF synchronizer 200 includes two other flip-flops, DFF_B1 240 and DFF_B2 250, which are located in CLK_B Domain 220. The CLK_B Domain 220 is of a different clock family than the CLK_A Domain 210.
When signal DA is propagated to DFF_B1 240 in the CLK_B Domain 220, DFF_B1 240 may enter a metastable state. If DFF_B1 240 does become metastable, there is a smaller probability that DFF_B2 250 will also become metastable because DFF_B2 250 is driven by DFF_B1 240. Thus, by allowing DFF_B2 250 (and not DFF_B1 240) to interact with the rest of the devices in CLK_B Domain 220 (i.e. devices after the 2DFF synchronizer 200), the probability that metastability will propagate may be reduced.
The single-bit 2DFF synchronizer 200 may reduce the probability that metastability will propagate, and thus may reduce the possibility of data corruption. However, the use of multiple single-bit synchronizers as a multiple-bit synchronization solution (i.e. a parallel synchronizer) may still lead to reconvergence violations. Reconvergence violations may occur when data signals driven by asynchronous clocks converge in subsequent logic. In other words, even though two data paths may be synchronized using single-bit synchronizers, the two synchronizers may output signals of different phases. The different phases may be due to variable and unpredictable delays caused by metastability. Reconvergence violations may be either combinational or sequential. Failure to correct reconvergence violations prior to silicon implementation may lead to functionality problems and possibly total chip failure.
One way to prevent reconvergence violations is to use a multiple-bit synchronizer where all of the outputs transition at the same time. For example, a MUX-based (DMUX) synchronizer may be used. A DMUX synchronizer is a multiple-bit synchronizer that combines 2DFF synchronization of control signals with MUX synchronization of data signals using the synchronized control signals.
Referring now to FIG. 3, a multiple-bit DMUX synchronizer 300 is shown. The DMUX synchronizer 300 may synchronize a data bus [D1:DN] transitioning from a CLK_A domain (i.e. a source domain) to a CLK_B domain (i.e. a destination domain). The data bus signals [D1:DN] and a synchronization control signal C are passed through D-flip-flops in the CLK_A domain. The control signal C is then passed through a single-bit 2DFF synchronizer 310 to synchronize it to the CLK_B domain. The output of the 2DFF synchronizer 310 is a synchronized control signal ME (i.e. synchronized to the CLK_B domain). The synchronized control signal ME may be used to control the MUXs in order to synchronize the data bus signals [D1:DN] to the CLK_B domain. Once the synchronized control signal ME goes high, the MUXs may pass stabilized data bus signals [D1:DN]. The stabilized data bus signals [D1:DN] are synchronized with the CLK_B domain when clocked through output D-flip-flops as synchronized data signals [DS1:DSN].
To illustrate the operation of a one-bit MUX-based synchronization, a MUX loop 320 is described. A MUX 330 drives a D-flip-flop 340 in the CLK_B domain and allows data bit D1 to pass from the CLK_A domain only when selected (i.e. when the MUX select signal, ME, is active). Otherwise, the MUX 330 re-circulates the D-flip-flop 340 output value, DS1. The functional check being performed here is that the source data signal D1 is stable when the MUX select signal ME goes high. Therefore, a reliable transition of bit D1 is made from the CLK_A domain to the CLK_B domain, and the bit D1 becomes synchronized with the CLK_B domain when it is clocked through the flip-flop 340.
Typical DMUX synchronizers may not tolerate synchronization where clock signals have an extreme frequency relationship (i.e. 10 to 1). In other words, the synchronized control signal ME may enable the MUXs before the input data bits [D1:DN] have stabilized at the MUX inputs, which may lead to logic errors that may propagate. Additionally, typical DMUX synchronizers are not able to tolerate synchronization where one clock signal may be extremely slow (or even stopped) at certain times. For example, a disk clock (i.e. DC_CLK) in a hard disk drive (HDD) may only be active during read/write operations. Lastly, typical DMUX synchronizers are not able to tolerate multiple synchronization requests (i.e. write sequences) during one synchronization cycle without loss of data, and thus a decrease in reliability.